A Two-Leveled Mobile Agent System for E-commerce with Constraint-Based Filtering

This paper presents a two-leveled mobile agent system for electronic commerce. It is based on mobile agents as mediators and uses the publish/subscribe paradigm for registration and transaction processing. In the system we present, suppliers can connect, register or unregister to the system at any time, thus preserving the dynamic nature of the system. To reduce network load and the flow of unnecessary information in the product brokering part of the buying process, a rule based subscription methodology is used for necessary filtering operations. 1 Two-Leveled Mobile Agent System Our work consists of a framework for a large-scale electronic commerce system that uses the publish/subscribe paradigm and exploits mobile agent technology extensively. It not only supports activities of buyers and suppliers, but also facilitates parallel computation by running mobile agents on suppliers concurrently. Our electronic commerce system involves three actors. Buyers look for purchase services from suppliers. Suppliers or sellers offer the services or products and a Dispatch Service facilitates communication between buyers and suppliers. The system consists of mobile agents that belong to two different levels of execution and responsibilities as shown in Figure 1: Broker level Mobile Agent (BMA) and Supplier level Mobile Agents (SMA). A BMA is created by a Buyer Agent (BA) and is sent to the Broker. This BMA creates SMAs and sends them to suppliers in order to search their databases, to select among products, and to negotiate with the supplier (if necessary). The system does not rely on only a single mobile agent that visits every supplier one by one. Instead, we send a replica of the mobile agent to each of the suppliers concurrently, and thus benefit the advantages of parallel processing. This model of parallel computation is especially important as more suppliers can be searched in a shorter time. In a dynamically changing electronic marketplace, a system should have the ability to adapt itself to this dynamic world. To meet this requirement, we have designed an architecture that utilizes the publish/subscribe paradigm for registration and dispatching operations, to increase efficiency and effectiveness of the procurement process in terms of costs, quality, performance, and time for both buyers and suppliers. The execution flow of the procurement process is as the following: 438 O.K. Sahingoz and N. Erdogan Fig. 1. Buying a product from a Supplier in Two-Leveled Mobile Agent System A number of buyers and suppliers have been subscribed to the system with their products and services. Their number in the system can vary randomly, increasing or decreasing at any time. When a user wants to buy a product, he has to make a request from the Buyer subsystem. A BA gets the request, creates a Mobile Agent, initializes its instance variables and sends it to the Broker as shown in Figure 1.a. When this Mobile Agent (we call it Broker level Mobile Agent (BMA)) arrives at the Broker, it checks the Knowledge Base of the Broker, selects the suppliers, which provide the requested products, and creates a new Supplier level Mobile Agent (SMA) for each of the selected suppliers. Thereafter, BMA sends each of these agents to a different supplier, as shown in Figure 1.b and Figure 1.c. Each SMA searches the product database of its supplier, negotiates with the supplier agent and sends results back to the BMA, as depicted in Figure 1.d. After all results have been collected from SMAs (or a specified timeout period has expired), BMA selects the best dealing one and sends an approval message to the SMA owning the deal, demanding it to buy the product and then to destroy itself. BMA sends rejection messages to all other SMA’s and they destroy themselves. BMA also sends a message that reports the negotiation and its result to the Buyer Agent, as depicted in Figure 1.e. We will now describe in more detail the main components of the system, the buyer and supplier subsystems and the dispatch system, explaining their functionality and discussing the major design decisions. Buyer Subsystem: To request a purchase order from the system, a buyer has to initialize a Buyer Subsystem on its machine. Buyers have to know the address (URL) of the broker agent that they will connect to, just as the URLs of well known web sites. The function of a Buyer Subsystem/Buyer Agent(BA) is to search for product A Two-Leveled Mobile Agent System for E-commerce 439 information and to perform goods or services acquisition. When a BA receives a purchase request from a user, it creates a Mobile Agent to search for product information and to perform goods or services acquisition in the system. BA specifies the criteria for the acquisition of the product and dispatches BMA to the broker. When BMA reaches the best deal, it sends a result report to BA and this information is added to its Database. As several transaction scenarios are possible, allowing users to generate Broker level Mobile Agents with different behavioral characteristics increases the flexibility of the system. A human user interacts with the BA via a Buyer GUI module. In the beginning of a transaction, the user supplies the necessary information (i.e. name, maximum price, quantity required and required delivery date of the product, etc.). The buyer GUI allows users to control and monitor the progress of transactions, and to query past transactions from its Database. Supplier Subsystem: A supplier has to initialize a Supplier Subsystem on its machine to join the system. When a supplier system is created for the first time, it subscribes to the system providing its address and the names of its products. If a supplier starts delivering a new product or ends the delivery of a former one, it again needs to subscribe or unsubscribe with product information, respectively. Every supplier agent has to know the address of the Broker so that it can make a connection. Supplier agent subscribes to the broker by sending its product definitions and waits for buyers to make requests for his products. Each SMA on the supplier side can access the Product Database in read mode, according to its interests. It determines whether the required quantity is already in the inventory and thus available to offer, and then makes negotiations (if necessary). If so, supplier agent gives an immediate quotation to the BMA and sends a result message. Dispatch Service: The Dispatch Service plays an important role in cyberspace. It is a logically (also physically in our system) centralized party which mediates between buyers and suppliers in a marketplace. The main component of the Dispatch Service is the “broker”. Broker is useful when a marketplace has a number of buyers and suppliers, when the search cost is relatively high or when trust services are necessary. In the system that we present, the broker implements the publish/subscribe paradigm in which purchase events are published and made available to the supplier components of the system through notifications. Filtering by Rules: To reduce unnecessary information in the product brokering, several filtering methods [1] have been widely used. In most of the E-commerce systems, only buyers make use of filters, but our system enables filtering for suppliers also. In other words, supplier selection process is carried out according to not only the buyer’s criteria, but also the supplier’s criteria. Buyers filtering criteria is loaded to BMA at the creation time by Buyer Agent, and BMA makes supplier selection process according to this. On the other hand, a supplier uploads its filtering criteria of a product as a rule in a subscription message at registration process of a product. This rule is store at the Subscription Table and BMA carries out it by examining the Subscription Table. 440 O.K. Sahingoz and N. Erdogan Our prototype system exploits a constraint-based filtering (as a rule), which makes use of textual annotations coded with content-based technique usually describing the products offered by e-commerce sites. Constraint-based filtering technique requires the definition of variables, domains and constraints. Therefore, many powerful algorithms such as backtracking, constraint propagation and variable ordering could be applied. PersonaLogic is an example of constraint-based filtering [2]. A rule is a set of attribute filters and it is sent in a subscription message at registration process of a product. Each attribute constraint is a tupple specifies a type, a name, a boolean binary operator, and a value for an attribute, as depicted in Figure 2. When a rule is used in a subscription, multiple constraints for the same attribute are interpreted as a conjunction; all such constraints must be matched one by one.